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AFTER FINAL EXPEDITED PROCEDURE 
REMARKS 

Claims 1 to 33 were pending in the application at the time 
of the office action. Claims 1 to 33 also remain rejected as 
anticipated. 

Claims 1 to 33 stand rejected under 35 U.S.C, §102 (e) as 
being anticipated by U.S. Patent Ho. 6,721,727, hereinafter 
referred to as Chau* 

Applicants respectfully continue to traverse the 
anticipation rejection of Claim 1. Prior to considering the 
rejection, Applicants first note that to make a prima facie 
anticipation rejection, the MPEP directs: 

TO ANTICIPATE A CLAIM, THE REFERENCE MUST TEACH EVERY 
ELEMENT OF THE CLAIM 

W A claim is anticipated only if each and every 
element as set forth in the claim is found, either 
expressly or inherently described, in a single prior art 
reference." . . . , < "The identical invention must be 
shown in as complete detail as is contained in the . . . 
claim. " Richardson v. Suzuki Motor Co., 868 F.2d 1226, 
1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989) . The elements 
must be arranged as required by the claim, but this is not 
an ipsissimis ve-rbis test, i.e., identity of terminology 
is not required. 

MPEP § 2131, 8th Ed., Rev. 5, p. 2100-67 (August 2006). It is 
noted that this directive stated the claim element " must be* 
shown in as complete detail and arranged as required by the 
claim. Thus, Chau must . show the invention to the same level of 
detail as recited in Claim 1. 

The MPEP puts forth specific criteria that are to be 
followed in interpreting a claim. These criteria will be 
quoted and applied to Claim 1. A comparison of the correct 
interpretation of Claim 1, as required by the MPEP, with Chau 
will demonstrate that the anticipation rejection of Claim 1 is 
not well founded. 
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The MPEP requires : 



*>USPTO< personnel must first determine the scope of a 
claim by thoroughly analyzing the language of the claim 
before determining if the claim complies with each 
statutory requirement for patentability (Emphasis in 
original . ) 
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MPEP § 2106 C, 8th Ed., Rev. 5, p 2100-6 (August 2006). 
The MPEP further requires : 

**>USPTO< personnel are to correlate each claim limitation 
to all portions of the disclosure that describe the claim 
limitation. This is to be done in all cases* *>, regardless 
of whether* the claimed invention is defined using means 
or step plus function language. The correlation step will 
ensure that *>USPTO< personnel correctly interpret each 
claim limitation. 

The subject matter of a properly construed claim is 
defined by the terms that limit its scope. It is this 
subject matter that must be examined, (Emphasis added.) 

MPEP § 2106 C, 8th Ed., Rev. 5, p 2100-7, (August 2006). 

while the Examiner is permitted to interpret the claim 
language broadly in construing the claim, the MPEP puts 
specific limitations on such an interpretation. For example, 

CLAIMS MUST BE GIVEN THEIR BROADEST REASONABLE 

INTERPRETATION 

During patent examination, the pending claims must be 
"given their broadest reasonable interpretation consistent 
with the specification." 

mpep § 2111 8th Ed. Rev. 5, p 2100-37 (August 2006) . 

The broadest reasonable interpretation of the claims 
must also be consistent with the interpretation that those 
skilled in the art would reach. 

MPEP § 2111 8th Ed. Rev. 5, p 2100-38 (August 2006) . 

This means that the words of the claim must be given their 
plain meaning unless **>the plain meaning is inconsistent 
with< the specification. In re Zletz, 893 F.2d 319, 321, 
13 USPQ2d 1320, 1322 (Fed. Cir. 1989) (discussed below) ; 
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Chef America, Inc. v. Lamb -Wes ton, Inc., 358 F.3d 1371, 
1372, 69 USPQ2d 1857 (Fed. Cir. 2004) (Ordinary, simple 
English words whose meaning is clear and unquestionable, 
absent any indication that their use in a particular 
context changes their meaning, are construed to mean exactly 
what they say. 

MPEP § 2111.01, I w 8th Ed. Rev. 5, p 2100-38 (August 2005). 

Claim 1 first recites " a markup document containing a 
plurality of elements and a plurality of attributes." Thus, a 
single markup document with more than one element and more than 
one attribute is recited. Since each recitation in Claim l 
refers back to these elements and attributes, the method is 
directed at processing the markup document . 

Claim 1 further recites: 

storing an element record for every element of said 
plurality of elements in an element table of said 
relational database so that said relational database 
includes a plurality of element records,' wherein each 
element record includes a unique element ID, and an 
element data set 

Claim 1 explicitly defines an element table. Further, 
Claim 1 recited what is stored in the element table, for 
example, "an element record for every element of said plurality 
of elements." Therefore, the element table includes a 
plurality of elements records because there is an element 
record for every element based on the plain meaning of the 
claim language and consequently "said relational database 
includes a plurality of element records." 

Also, as taught by Chau, elements are a subset of an XML 
document and so an interpretation of "element 1 " must be 
consistent with the usage in Chau and consistent with the 
requirement of Claim 1 that the elements are contained in a 
markup document, because to use a different definition is 
consistent with neither the level of skill in the art as 
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AFTER FINAL EXPEDITED PROCEDURE 

established by Chau nor the plain meaning of the claim 
language . 

Also, Claim 1 recites that each element record includes an 
identifier and not just any identifier,, but rather a specific 
identifier, an "element identifier". Claim 1 further recites 
that the element identifier is unique- An element identifier 
is unique only if it is the only one. Therefore, the plain 
meaning of Claim 1 is that each element record includes a 
different element identifier, because otherwise the element 
identifier is not unique ♦ The fact that each element 
identifier is unique means that the element identifier can be 
used to identify the element data set in that element record. 

Claim 1 also recited: 

wherein 'said element table and said' attribute table 
include content of said markup document and further 
wherein a new markup document having a same content as 
said markup document can be constructed by retrieving said 
element data set in each of said plurality of element 
records stored in said element table of said relational 
database 

Thus, the element table is further defined as including 
"content of said markup document" and "a new markup document 
having a same content as said markup document can be 
constructed" by using the element data sets stored in the 
element table. Again, a single markup document is recited and 
not multiple markup documents that were used in the rejection. 

The rejection does not cite any teaching of such a table 
or records in Chau and instead stated: 

chau teaches the claimed step of "storing an element 
record for every element of said plurality of elements in 
an element table of said relational database, wherein each 
element record includes a unique element ID, and an 
element data set" as XML enables storing entire XML 
documents into a database . 
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Note that the quoted language is not from Chau, but rather 
from Applicants ' Claim 1- The rejection continues: 

The root_id in the application table is unique 
element ID and the user creates root_id as a primary key 
of the application table. When there is no primary key in 
the table, then XML system create a primary key as 
DXXROOT_ID and all side tables will have this key (Fig. 3, 
col. 6, lines 38-40; col. 18, line 67 to col. 19, line 1 
and col. 17, lines 55-61) . 



- . . whereas Application table 3 00 corresponds to 
element table . . . 



Each of the citations in Chau is considered and then Chau 
is considered in further detail. Fig. 3 of Chau shows "an 
application or main table and its four side tables.* 1 Chau, 
Col. 3, lines 33 and 34. The application table in Fig. 3 fails 
to show any element records in the same detail as recited in 
Claim 1. The root_id is not described as being associated with 
an element and in fact it is described as a primary key for the 
application table in the rejection rather than being associated 
with a specific element record as recited in Claim 1. 

Col » 6, lines 38 to 40 of Chau taught: 

With native XML formatted documents, XML enableB 
storing entire XML documents into a database and searching 
on known elements or attributes 

This general statement teaches nothing concerning how the 
documents are stored and so is not sufficient under the 
directions of the MPEP to anticipate the sections of Claim 1 
just quoted. 

Chau, Col. 18, line 67 to Col, 19, line 1 taught: 

FIG. 3 illustrates an application or main table and 
its four side tables. The Application table 300 has a 
root id in common with each side table 3 02, 3 04, 3 06, and 



Page 6 of 14 



PAGE 9/10 * RCVD AT 912012006 5:11:56 PM [Eastern Daylight Time] 1 SVR:USPTO-EFXRF-3/13* DNIS:2738300 * CSID:831 655 0888 * DURATION (mm*s):03-04 



BEST AVAILABLE COPY 



09/20/06 



13:12 FAX 831 655 0888 



GUNNISON MCKAY HODGSON 



Eioio 



Appl. No. 10/054,544 

Amdt. dated September 20, 200 6 

Reply to Office Action of July 20 , 2006 

AFTER FINAL EXPEDITED PROCEDURE 

308. The side tables 302, 304, 306, and 308 correspond to 
the side 'tables defined in the DAD above. 



while Chau, Col. 17, lines 55 to 61 taught: 

A user can decide whether the primary key of the 
application table is to be the "root id" . If the primary 
key does not exist in the application table, or for some 
reason a user doesn't want to use the primary key, then 
XMTi fiVfltem will al tpr Anrvl i r*at i r>n t^h"l<=> tr> «rl<i a rnlnmn 
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308. The side tables 302, 304, 306 , and 308 correspond to 
the side tables defined in the DAD above. 



while Chau, Col- 17 7 lines 55 to 61 taught: 

A user can decide whether the primary key of the 
application table is to be the "root id" . If the primary 
key does not exist in the application table, or for some 
reason a user doesn»t want to use the primary key, then 
XML System will alter application table to add a column 
DXXROOT_ID for storing a unique identifier created at 
insertion time (i.e., when data is inserted into the 
application or main table) . (Emphasis Added) 

None of these references teach exactly the structure of 
Claim 1 as quoted above. Further, the only basis of the 
interpretation, as shown in the rejection, is Applicants' claim 
language. Chau teaches that the application table is 
fundamentally different from the element table of Claim 1. 

First, Chau unambiguously explains that the application 
table is not an element table as recited in Claim 1- 

One embodiment of the invention provides an XML 
System which solves the problem of fast searching and 
indexing of XML element/attribute values of XML documents 
when they are stored inside a database as column data . 
( Emphas i s added * ) 

Chau, Col. 16, lines 2 6 to 30 

Thus, Chau expressly stated that XML documents are stored 
as column data and teaches nothing concerning element records 
of an element table as recited in Claim 1. According to Chau, 
the entire content of an XML document is stored in a column. 
There is no ambiguity as to this fact, because Chau stated 

... an XML column is used to store entire XML 
documents . . 
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The XML System provides several user defined types 
(UDTs) for XML columns. These data types are used to 
identify the storage types of XML documents in the 
application table. 

Chau, Col* 8, lines 14 to 17. 

Finally, 

D.3 XML Column/User Defined Types 

An XML column is designed to store XML documents in 
their native format in the database as column data , . . . 
. An XML column is created when a user creates or alters 
an application table. (Emphasis Added) 

Chau, Col. 19, lines 4 to 21. 



D.8 Inserting XML Documents 

For XML columns , an entire XML document is always 
stored as the column data. (Emphasis Added) 



Chau, Col. 22, lines 13 to 15. 
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Thus, Chau expressly taught that an XML document is stored 
in its native format, and that XML columns are used in the 
application table cited in the rejection of Claim 1. Storing 
an XML document its native format in a column teaches away from 
the element table and the specific structure of that table as 
recited in Claim 1. Further, the root id of Chau fails to 
teach anything concerning a unique element ID" for an element 
data set. At best it is understood, the rejection relies upon 
multiple XML documents that each have a different root_id so 
that the application table looks like: 



root idl 


Entire XML document 1 


root id2 


Entire XML document 2 



Page 8 of 14 



PAGE 319 * RCVD AT 9/2012006 5:18:02 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-2/15 * DNIS:2738300 * CSID:831 655 0888 1 DURATION (mm-ss):03-16 

BEST AVAILABLE COPY 



09/20/06 13:17 FAX 831 655 0888 



GUNNISON MCKAY HODGSON 



E1012/017 



Appl. No. 10/054,544 

Amdt. dated September 20 , 2006 

Reply to Office Action of July 20, 2006 



AFTER PINAL EXPEDITED PROCEDURE 



root id3 



Entire XML document 3 
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The rejection apparently reads an element record on the unique 
root_id for the entire XML document and the element data set is 
assumed to be the entire XML document. 

This is error for multiple reasons. First, it requires 
multiple XML documents and the element data sets are not for a 
single XML document, but rather for three different XML 
documents in the above example. The element data sets of 
Claim 1 are associated with the "markup document containing a 
plurality of elements." 

A single unique ID for the entire XML document and storing 
the complete XML document fails to teach an element record for 
each of a plurality of elements in a "markup document 
containing a plurality of elements." A single record with a 
unique root^id and the entire XML document fails to teach "an 
element record for every element of said plurality of elements" 
in a "markup document containing a plurality of elements" "so 
that said relational database includes a plurality of element 
records . " 

The root_id of Chau is not described as being unique for 
each element in the XML document but rather unique with respect 
to the entire XML document. There has been no showing that the 
root_ID can be used to distinguish between different element 
data sets within a single XML document of Chau. Conversely, 
since each element ID of Claim 1 is unique, the element ID 
identifies a specific element data set in the element table. 
According to Chau, the entire content of an XML document is 
stored in a column and not an element data set of the document 
as recited in Claim 1. 

As noted above, Claim 1 recites a single' markup document 
and not multiple documents as stated at page 20, the first full 
paragraph of final office action dated July 20, 2006. 
Therefore, the Office has on the record admitted the Office's 
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interpretation of Chau fails to teach exactly the element table 
with the characteristics recited in Claim 1. 
Nevertheless, the rejection continues: 

Further, Chau teaches the claimed step of "storing an 
attribute record for every attribute of said plurality of 
attributes in an attribute table of said relational 
database so that said relational database includes a 
plurality of attribute records, wherein said attribute 
record comprises an attribute data set for one attribute 
and an element ID of an element to which' the one attribute 
is assigned wherein said element table and said attribute 
table include content of said markup document and further 
wherein a new markup document having a same content as 
said markup document can be constructed by retrieving said 
element data set in each of said plurality of element 
records stored in said element table of said relational 
database and by retrieving said attribute data set in each 
of said plurality of attribute records stored in said 
attribute table of said relational database" as the side 
tables 302, 304, 306 and 308 correspond to the attribute 
tables .... Side tables are dependent on the 
Application table and side tables also use the same 
root_id or the XML system created primary key 
DXXROOT_ID( (Fig. 3, col . 18, line 67 to col. 19, line 1 
and col. 17, lines 61-63; col. 7, lines 38-39; col. S, 
lines 22-24 and col. 24, lines 50-67). 

Again, the interpretation relies upon Applicants 1 claim 
language and not any teaching in Chau- chau explicitly taught 
that side tables 306 and 308 did not include attributes (See 
Chau, Col. 18, lines 59 to 62). Further, the interpretation 
ignores the explicit teaching in Chau on how to compose XML 
documents- - "FIG . 10 is a flow diagram illustrating the process 
performed by the XML system using RDB_node mapping to compose 
XML documents."-- and how to decompose XML document - - " FIG . 11 
is a flow diagram illustrating the steps performed by the XML 
System to decompose XML documents with application specific 
mappings." The processes disclosed in this diagrams are 
fundamentally different from that recited in Claim 1, but yet 
the rejection argues that one of skill in the art would ignore 
these teachings and would read Chau to teach exactly the method 
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of Claim 1 despite the fact, as pointed out below, that Chau 
teaches the information relied upon in the rejection is an 
indexing system used for searching and not the method of 
Claim 1 . 

Chau does not teach that the elements in the side tables 
are created to include element data sets for content of an XML 
document and to retrieve those element data sets for content in 
another XML document. First, Chau requires a programmer to 
specify what is included in the side tables, i.e., 

The embodiment of the invention permits application 
programmers to define a Data Access Definition (DAD) which 
identifies the XML elements or attributes that need to be 
indexed and defines the mapping between XML elements or 
attributes to columns in one or more side tables. The DAD 
is an XML formatted document that is used to specify 
within an XML document which elements or attributes are to 
be searched. (Emphasis Added) 

Chau, Col. 16, lines 45 to 52 . 

Thus, the side table content is specified by the 
application programmer to identify attributes, that need to 
indexed. This teaches away from selecting element data sets so 
that the content of a markup document can be included in a new 
markup document- Chau repeats that the side tables are for a 
limited specific purpose, searching, and not for reconstructing 
content as recited in Claim 1 . 

Additionally, the embodiment of the invention stores 
XML document data in an application table, while storing 
particular elements or attributes in side tables . The data 
stored in the side tables is referred to as "metadata" and 
is used to search for elements or attributes in the XML 
documents stored as column data in the application table . 
During the enabling of a column which contains XML 
documents, side tables are created (based on the DAD) to 
store duplicate data of these elements or attributes. 
(Emphasis Added) 

Chau, Col. 16, lines 59 to 67. 
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Thus, Chau unambiguously taught, as previously pointed 
out, that the xml documents are stored in a column of the main 
table, while side tables are created based on a DAD that an 
application programmer specifies and are used in searching of 
the XML documents stored in the column. The rejection still 
has not cited any teaching that data is retrieved from the side 
table to reconstruct the content of the document and in fact, 
Fig. 10 of Chau contradicts the conclusory rejection. 
Accordingly, Chau fails to teach the method of Claim 1 in the 
same level of detail as recited in Claim 1. Applicants 
j respectfully request reconsideration and withdrawal of the 

anticipation rejection of Claim 1. 
! Claims 2, 5 and 8 to 11 depend from Claim 1 and so 

distinguish over the prior art for at least the same reasons as 
Claim 1 that were discussed above. Applicants request 
reconsideration and withdrawal of the anticipation rejection of 
each of Claims 2, 5 and 8 to 11. 

Claims 3 and 4 recite "said element data set contains a 
parent element ID.' 1 The rejection previously cited the root id 
of Chau as teaching exactly the unique element identifier in 
the element record. The rejection of these claims again cites 
the root id of Chau. The root id of Chau cannot teach exactly 
both the unique element identifier and a parent element ID in 
the element data set. This is but further evidence the 
explicit claim limitations have been ignored. One of the 
rejections must be wrong. Also, Claims 3 and 4 depend from 
Claim 1 and so distinguish over the prior art for at least the 
j same reasons as Claim 1 that were discussed above. Applicants 
! request reconsideration and withdrawal of the anticipation 
rejection of each of Claims 3 and 4. 

With respect to the anticipation rejection of Claims 6 and 
7 , the rejection cited to a portion of a description of how to 
write a DAD by an application programmer. This description 
cnr^o*^* fails to mention storing only for "every unique element name of 
j^j2g5 B the plurality of elements." It also does not teach the element 

Muxaqt. CA 959*0 
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name record or a unique element name ID is defined only for 
such elements. The cited description fails to mention storing 
only for "every unique attribute name of the plurality of 
attributes. 11 It also does not teach the attribute name record 
or a unique attribute name ID. Also, Claims 6 and 7 depend 
from Claim 1 and so distinguish over the prior art for at least 
the same reasons as Claim 1 that were discussed above. 
Applicants request reconsideration and withdrawal of the • 
anticipation rejection of each of Claims 6 and 7. 

Claim 12 recites storing particular information in a 
particular way in four different tables. Further, Claim 12 
includes language similar to that discussed above with respect 
to Claim 1 and so the remarks with respect to Claim 1 are 
applicable to Claim 12, and are incorporated herein by 
reference. Also, the comments with respect to Claims 6 and 7 
are incorporated herein by reference. Applicants request 
reconsideration and withdrawal of the anticipation rejection of 
Claim 12. 

Claims 13 to 15 depend from Claim 12 and so distinguish 
over the prior art for at least the same reasons as Claim 12 
that were discussed above. Applicants request reconsideration 
and withdrawal of the anticipation rejection of each of 
Claims 13 to 15. 

Each of independent Claims 16, 26, and 3 0 stand rejected 
based upon substantially the same rationale as Claim 1. Each 
of these claims, includes language similar to that discussed 
above with respect to Claim 1 and so the remarks with respect 
to Claim 1 are applicable for each of these claims and are 
incorporated herein by reference with respect to each. 
Applicants request reconsideration and withdrawal of the 
anticipation rejection of each of Claims 12, 16, 26, and 30. 

Claims 17 to 25 depend from Claim 16 and so distinguish 
over the prior art for at least the same reasons as Claim 16 
that were discussed above. Applicants request reconsideration 
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and withdrawal of the anticipation rejection of each of 

Claims 17 to 25, 

Claims 27 to 2 9 depend from Claim 26 and so distinguish 
over the prior art for at least the same reasons as Claim 26 
that were discussed above. Applicants request reconsideration 
and withdrawal of the anticipation rejection of each of 
Claims 27 to 29. 

Claims 31 to 33 depend from Claim 30 and so distinguish 
over the prior art for at least the same reasons as Claim 30 
that were discussed above. Applicants request reconsideration 
and withdrawal of the anticipation rejection of each of 
Claims 31 to 33. 

Claims 1 to 33 remain in the application!. For the 
foregoing reasons, Applicant (s) respectfully request allowance 
of all pending claims. If the Examiner has any questions 
relating to the above, the Examiner is respectfully requested 
to telephone the undersigned Attorney for Applicant (s) . 
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and Trademark Office, Fax Mo. 571-273-9300, on 
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Rivkah. Young 
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Respectfully submitted, 

Forrest Gunnison 
Attorney for Applicant (s) 
Reg. No. 32,899 
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